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(57) ABSTRACT 

A transaction time measurement mechanism has a transac- 
tion time manager running on a server computer system, a 
transaction time agent running on a client computer system 
that is coupled to the server computer system via a network, 
and a simple protocol for allowing them to directly and 
efficiently communicate. The transaction time agent is con- 
figured according to configuration data stored in a configu- 
ration table in a transaction time database, and stores trans- 
action time data in a statistics table according to this 
configuration. The data in the statistics table is indexed to 
allow retrieving only the transaction time data of interest. 
The simple communication protocol supports multiple trans- 
action time managers in a network computing environment 
that may all communicate with a single client. 
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APPARATUS AND METHOD FOR stream to determine when and how to pass the data between 

MEASURING TRANSACTION TIME IN A host 110 and terminals 130. As a result, integrating a 

COMPUTER SYSTEM response time measurement mechanism 160 into communi- 
cations controller 120 is relatively straightforward. 

BACKGROUND OF THE INVENTION 5 Response time measurement mechanism 160 includes a 

1 Technical Field response time collector 140 and a response time list 150. A 

. . „ response time collector 140 determines the user-perceived 

This invention generally relates to computer systems, and nse timCj and st0fes mis information in a response lime 

more specifically relates to an apparatus and method for lisl 150 The se lime ^ctor 140 starts a timer when 

measuring transaction time in a computer system. ^ the ^ pregses me tlEmer >. key Qn his 0f her terminal) and 

2. Background Art slops lne timer when host 110 sends the "keyboard unlock" 

The development of the EDVAC computer system of message back to that terminal. Response time collector 140 

1948 is often cited as the beginning of the computer era. then stores the response time in response lime list 150. The 

Since that time, computer systems have evolved into contents of response time list 150 may be accessed by host 

extremely sophisticated devices, and computer systems may 1S 110 as needed. Response time monitoring mechanism 160 

be found in many different environments. Since the dawn of thus provides a simple way to accurately determine the 

the computer age, the performance of computers has been user-perceived response time in a host computing environ - 

measured to determine how well the computer performs ment 100. However, determining the user-perceived 

certain tasks. One measure of computer performance is response time in a network computer environment presents 

response time, which is used herein to broadly define the 2Q greater challenges. 

time it takes the computer to perform a specific task or The widespread proliferation of computers prompted the 

transaction. Generally, the response time that is of most development of computer networks that allow computers to 

interest is the user-perceived response time. For a single user communicate with each other. With the introduction of the 

on a single stand-alone computer system, the user-perceived personal computer (PC), computing became accessible to 

response time is virtually the same as the time it takes the 25 large numbers of people. Networks for personal computers 

computer to perform the desired task or transaction. were developed that allow individual users to communicate 

However, as multiple users and computers are added, the with each other. In this manner, a large number of people 

user-perceived response time is different than the processing within a company, for example, could communicate at the 

time for the task on a single computer. same time with a software application running on one 

In the early days of computers, one or more relatively 30 computer system. A computing system that includes mul- 

powerful and expensive computers could be shared by many tiple computers communicating over a network is generi- 

users. Referring to FIG. 1, a number of computer terminals cally referred to herein as a network computing environ- 

130 were typically connected to a single computer 110 ment. One example of a suitable network computing 

known as a "host." These computer terminals 130 are environment 200 is shown in FIG. 2, and includes a server 

commonly known as non -programmable workstations (i.e., 35 computer system 210 communicating over a network with 

"dumb terminals") because they simply display information multiple clients 230. 

transmitted to it by the host, and lack any processing power Today, computer networks are ubiquitous, and great time 
to perform local tasks. One example of a very well-known and effort is being expended to increase the performance of 
computer terminal is the IBM 5250, which displays alpha- computer networks. One aspect of performance is the user- 
numeric text in row and column format. In a computing 40 perceived response time. However, with computers in a 
environment 100 with a host 110 and one or more terminals network computing environment, known network protocols 
130 (referred to herein as a host computing environment), a do not provide any uniform mechanism for determining 
communications controller 120 was typically included to user-perceived response time. So important are user- 
facilitate the communications between the single host 110 perceived response times that some consultants are now 
and multiple terminals 130. In a host computing environ- 45 basing their fees on the improvement in user-perceived 
ment 100, software applications run on host 110, and display response times they are able to achieve. Therefore, mea- 
information is transmitted by host 110 via communications surement of user-perceived response time is critically impor- 
controller 120 to terminals 130. In this manner a user sitting tarn. The problem of accurately measuring user-perceived 
at a particular terminal 130 may start an application on host response time in a network computing environment is com - 
110, and host 110 will then display an appropriate screen to 50 plicated by the fact that multi ple cojn puters on the network 
the user at the appropriate terminal 130. The user may then may process sub-parts of a task or transaction in parallel, so 
enter data in response to the displayed screen, if required. the different computers that perform the various sub-tasks 
A host computer and its dumb terminals communicate will not know when the entire task or transaction is co ro- 
using an architected data stream that determines the action plete. The focus of response time measurements in a net- 
to be taken when certain characters are transmitted back and 55 work computing environment have been on measuring trans- 
forth. When the user desires to perform a task or transaction, action times. Transaction time is the time required for a 
the user inputs the appropriate information on the screen to transaction to go from start to finish, regardless of how the 
start the task, and presses the enter key to send this infor- various steps are accomplished. For the discussion herein, 
mation to the host in a data stream. The host takes the the term transaction time is understood to be the user- 
information, processes the information appropriately, 60 perceived response time. 

returns data to the dumb terminal in a data stream (that is One possible solution to monitoring user-perceived 

typically displayed on the screen), and then unlocks the response time is illustrated in FIG. 2, and would place a 

keyboard for further input by the user. response time measurement mechanism 260 in the server 

Determining the user-perceived response time in a host computer system 210. Response time measurement mecha- 

computing environment is relatively straightforward by 65 nism 260 could have a response time collector 240 and a 

monitoring the data stream between the host and the termi- response time list 250. Response time collector 240 would 

nals. The communications controller 120 monitors the data actively monitor and interrogate each client 230 to deter- 
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mine response times, and would store these response times oriented software, the Overview section below presents 

in response time list 250. This solution, however, takes background material for understanding the preferred 

considerable processing power and excessive overhead, embodiments described below, 

which would significantly degrade system performance. For Overview 

this reason, this solution has not been implemented in 5 object Oriented Programming 

large-scale networks. One of the relatively recent advances in the field of 

The prior art methods of measuring response time in a software development has been the emergence of object 

network computing environment have excessive overhead, oriented programming technology. The goal of using object- 

and arc not easily implemented. Therefore, there existed a oriented programming is to create small, reusable sections of 

need to provide a response time monitoring mechanism that 10 program code known as objects that can be quickly and 

efficiently collects response times in a network computing easilv combined and re-used to create new programs. This is 

environment without introducing excessive overhead. similar to the idea of using the same set of building blocks 

again and again to create many different structures. The 

DISCLOSURE OF INVENTION modular and re-usable aspects of objects typically speeds 

15 development of new programs, thereby reducing the costs 

According to preferred embodiments of the present associated with the development cycle. In addition, by 

invention, a transaction time measurement mechanism has a creating and re-using a group of well-tested objects, a more 

transaction time manager running on a server computer stable> uni f orni) and consistent approach to developing new 

system, a transaction time agent running on a client com- computer programs can be achieved, 

puter system that is coupled to the server computer system 20 0ne of lhe ideas in object orien ted programming 

via a network, and a simple protocol for allowing them to ^ the concept of a class. A class is a definition of a set of like 

directly and efficiently communicate. The transaction time objects. As such, a class can be thought of as an abstraction 

agent is configured according to configuration data stored in of the objects or as a definition of a type of object. From the 

a configuration table in a transaction time database, and view 0 f a computer system, a single object represents an 

stores transaction time data in a statistics table according to 25 encapsulated set of data and the operation or a group of 

this configuration. The data in the statistics table is indexed operations that are performed by a computer system upon 

to allow retrieving only the transaction time data of interest. tnat dala 

The simple communication protocol supports multiple trans- Each class definition comprises data definitions that 

action time managers in a network computing environment define lhe information controlled by the object and operation 

that may all communicate with a single client. 30 definitions that define the operation or operations performed 

The foregoing and other features and advantages of the by objects on the data that each object controls. In other 

invention will be apparent from the following more particu- words, a class definition defines how an object acts and 

lar description of preferred embodiments of the invention, as reacts to other objects by defining an operation or set of 

illustrated in the accompanying drawings. operations that is/are performed on the defined data. (Please 

35 note that operations are sometimes called methods, method 

BRIEF DESCRIPTION OF DRAWINGS programs, and/or member functions.) Objects interact by 

The preferred embodiments of the present invention will ^okiijg their own methods or by invoking methods on 

hereinafter be described in conjunction with the appended ° ther ob J ec *- together the defined methods and 

drawings, where like designations denote like elements, and: d u ata are f aid <° j> e lhe , be fl haV10r u of u tt ! e ° bject f ! n esse " ce ' 

. . - L . 40 then, a class definition defines the behavior of its member 

FIG. 1 is a block diagram of a computer system showing Qbject of Qbjects Qbjects afe instanliated ^ members of a 

response time measurement in a host computing environ- ^ and afe oflen referred lQ ^ inslanceS( 

meDli Description of the Preferred Embodiments 

FIG. 2 is a block diagram of a computer system showing According to preferred embodiments disclosed herein, 

one possible method for collecting response time measure- 45 user-perceived response times are monitored by determining 

ments in a network computing environment; me time it takes for a transaction to complete. A transaction 

FIG. 3 is a block diagram a computer system showing a time measuring mechanism is provided that allows transac- 

possible method for collecting transaction time measure- tion time data to be efficiently collected over a standard 

ments in a network computing environment; interface in a manner that provides minimal network 

FIG. 4 is a block diagram of a computer system for 50 overhead, and that allows for multiple transaction time 

collecting transaction time measurements in a network com- managers on multiple server systems in a network comput- 

puting environment according to a preferred embodiment of ing environment. 

the present invention- One possible solution to monitoring user-perceived 

FIG. 5 is a block diagram of the configuration table shown res P° nse j s P resented herein wilh I ?£S Bn ? * 

in FIG 4- 55 s P eci ^ c network computing environment 300 or FIG. 3, 

„ ' ' , , , , . L1 . . which is representative of a system developed by Tivoli 

FIG. 6 is a block diagram of the statistics table shown in Systems , nc Qf Jqx N ^ Q± mmpvl mg environ- 

4, and ment mc i udes a first server 310, a second server 320, a 

FIG. 7 is a flow diagram of steps that may be performed mird server 330, and a client 340. While network computing 

in measuring transaction times according to a method in 60 environment 300 is illustrated in FIG. 3 with a single client 

accordance with a preferred embodiment. f or simplicity of illustration, the actual configuration will 

DCCT x^r.c nr , 0 rADDV , WP niITTU r include multiple clients, as is common on most computer 

BEST MODE FOR CARRYING OUT THE We mc fof ^ purposes of iUustrating tnis 

possible solution that: server system 1 (310) includes a 

The transaction time monitoring mechanisms of the 65 server application 1 (312); server system 2 (320) includes a 

present invention will be discussed in terms of object transaction time manager 322 and an Object Request Broker 

oriented software. For those that are not familiar with object (ORB) 324; and server system 3 (330) includes a server 
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application 3 (332). Server applications 1 (312) and 3 (332) ing of objects across a wide variety of hardware platforms 

represent portions of applications 1 and 3 that run on a and operating systems. CORBA allows applications to com - 

server. Note that there are corresponding pieces of these municate with one another regardless of location or vendor, 

applications running on client 340, discussed below. Trans- In particular, CO RBA defines inter-operability by specifying 

action time manager 322 and ORB 324 are portions of a 5 the design and interaction behavior of Object Request Bro- 

transaction time measurement mechanism 390, discussed in kers (ORBs) such that ORBs from different vendors can 

more detail below. effectively communicate and inter-operate with each other. 

Client system 340 includes a client application 1 (314), a This has been accomplished by defining the application 

client application 3 (334), a transaction time agent 360, an interface protocol in a language-independent specification, 

application response measurement (ARM) application pro- 10 Detailed information on the OMG and the CORBA speci- 

gram interface (API) 370, a configuration file 380, a log file fication is available on the World Wide Web at hup:// 

382, and a statistics database 384. Client applications 1 www.omg.org. 

(314) and 3 (334) represent the portions of applications 1 Another important application program that is used in a 
and 3 that run on client 340. Client application 1 (314) typical object-oriented environment is known as the Object 
communicates with server application 1 (312) via a standard is Request Broker (ORB). The ORB establishes client-server 
network protocol, such as hypertext transfer protocol (hup), relationships between various objects. ORBs are a well 
TCP/IP, or IBM 5250 protocol. Client application 3 (334) known technology that allows an application on one 
also communicates with server application 3 (332) via a machine to invoke methods on objects that reside on another 
standard network protocol. The components of client 340 machine. ORBs provide the infrastructure that allows 
other than client application 1 (314) and 3 (334) shown in 20 objects to converse with each other, independent of the 
FIG. 3 are part of transaction time measurement mechanism specific platforms and techniques used to implement the 
390. various objects. Using an ORB, a client object can trans- 
Transaction time measurement mechanism 390 includes parently invoke a method on a server object, whether the 
transaction time manager 322 and ORB 324 in server system server object is located on the same machine or on a different 
2 (320); gateway 350 with its ORB 352; and transaction time 25 machine connected via a network. The ORB operates by 
agent 360, ARM API 370, config file 380, log file 382, and intercepting method calls and finding an object that can 
statistics database 384 on client 340. Transaction time man- implement the request, passing the request parameters to the 
ager 322 controls the operation of transaction time measure- object, invoking the method, and returning the results. While 
ment mechanism 390. Transaction time agent 360 resides on doing so, the client need not be aware of where the object is 
client 340 and collects response times according to infor- 30 located, the programming language of the object, the oper- 
mation in the config file 380. ARM API 370 is suitably a ating system of the object, or any other system-related 
Tivoli-HP ARM or similar API that allows the agent to aspects. Thus, the ORB provides inter-operability between 
record transaction times by having the application call the applications on different machines in heterogeneous distrib- 
API at both the beginning and the end of the transaction. uted environments and seamlessly interconnects multiple 
Thus, ARM API 370 is called by client system 340 to start 35 object systems. 

and stop transaction times in transaction time agent 360. Thus, an ORB on one computer system is used to com- 

Config file 380 defines one or more fields that determine the municate with an ORB on another computer system. For the 

operation of transaction time agent 360, such as thresholds networked computer system of FIG. 3, ORB 324 commu- 

for response times, whether or not the response times are nicates with ORB 352 in gateway 350. The protocol for 

reported and to whom, etc. Log file 382 contains historical 40 communicating between ORBs results in a heavy interface, 

information relating to the transaction times collected by one that requires significant overhead. Gateway 350 receives 

transaction time agent 360. Config file 380 and log file 382 data from ORB 352, and communicates this data to client 

are typically flat files, and data is written to and read from 340 via a light interface, such as a peer-to-peer network 

these files by programs on the local system or remote connection. 

systems using standard file input/output operations and 45 Imposing the requirements of ORBs on the interface 
remote file transfer mechanisms. Thus, if historical response between portions of response time collection mechanism 
time data for a particular application (e.g., application 1) are 390 results in unneeded complexity and overhead in col- 
desired from the log file 382, all of the data must be read and lecting response times. In addition, network computing 
processed to determine which data correspond to application environment 300 of FIG. 3 only has a single transaction time 
1. Statistics database 384 contains a list of all response times 50 manager 322 on one server, and has no provision for 
collected by transaction time agent 360 for all applications multiple transaction time managers in multiple servers, 
on all servers. These limitations are overcome by a network computing 

Gateway 350 and ORBs 324 and 352 provide a mecha- environment in accordance with the preferred embodiment, 

nism for server system 2 (320) to communicate with client Referring to FIG. 4, a suitable network computing envi- 

system 340. Gateway 350 is a piece of software that may 55 ronment 400 in accordance with the preferred embodiment 

reside on any server on the network. ORB 324 and ORB 352 overcomes the limitations of network computing environ- 

intercommunicate in accordance with well-known and ment 300 of FIG. 3 by including a transaction time mea- 

defined standards discussed below. surement mechanism 490 that communicates between client 

The Object Management Group (OMG) is a standards and server over a simple, light, standard interface, such as 

group formed by a large alliance of software companies to 60 SNMP. Network computing environment 400 includes: a 

help standardize object software. The goal of the group is to server system 1 (410), a server system 2 (420), a server 

provide specifications that form a common framework for system 3 (430), and a client system 440 interconnected via 

object-based application development. This reduces the a network. As with network computing environment 300 of 

complexity and lowers the cost of introducing new or FIG. 3, network computing environment 400 is understood 

enhanced object-based software applications. The Common 65 to include multiple clients. For the purposes of the preferred 

Object Request Broker Architecture (CORBA) is an OMG embodiment herein, the present invention applies equally no 

specification designed to provide a framework for the shar- matter how the different computer systems in network 
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computing environ men 1 400 are interconnected, regardless 
of whether the connections are is made using present-day 
analog and/or digital techniques or via some networking 
mechanism of the future. Server system 1 includes a server 
application 1 (412), and also includes a transaction time 
manager 414. Server system 2 (420) includes a transaction 
time manager 422. Server system 3 (430) includes a server 
application 3 (432) and further includes a transaction time 
manager 434. For the purposes herein, a "server system" is 
used in its broadest sense to mean any system that may 
interact with client system 440, 

Client system 440 includes a client application 1 (414), a 
client application 3 (434), a transaction time agent 460, an 
ARM API 470, and a transaction time database 480. Similar 
to network computing environment 300 in FIG. 3, transac- 
tion time agent 460 communicates with client applications 1 
(414) and 3 (434) via ARM API 470. However, instead of 
communicating with a gateway 350 that includes an ORB 
352, transaction time agent 460 communicates directly with 
transaction time managers 414, 422, and 434 via SNMP 
interfaces. SNMP is a standard that is presented in Request 
for Comment (RFC) 1157, and was developed by the Inter- 
net Engineering Task Force (IETF). Details regarding the 
SNMP standard may be found at www.internic.net. The 
SNMP protocol is a light protocol that does not require 
significant network overhead, unlike the protocol for com- 
municating between ORBs. 

A significant advantage of network computing environ- 
ment 400 of the preferred embodiment over known systems 
and the network computing environment 300 (FIG. 3) is that 
network computing environment 400 allows a single trans- 
action time agent 460 to communicate with multiple trans- 
action time managers 414, 422, and 434. Another significant 
advantage is that the communication between transaction 
time agent 460 and transaction time managers 414, 422, and 
434 does not require the heavy interface that ORBs require, 
but uses instead a standard, light SNMP protocol. In 
addition, transaction time database 480 provides an indexed 
database that may be queried rather than flat files. As a 
result, portions of config table 482 and stats table 484 may 
be written to or read from without writing/reading the entire 
file, as was the case for network computing environment 
300. Transaction time database 480 therefore allows for 
efficient retrieval of only certain transaction time data. For 
example, if server system 1 (410) is only interested in the 
transaction times for client application 1, transaction time 
agent 460 may efficiently retrieve only the requested infor- 
mation from stats table 484. 

At this point, it is important to note that while the present 
invention has been (and will continue to be) described in the 
context of a fully functional computer system, those skilled 
in the art will appreciate that the mechanisms of the present 
invention are capable of being distributed as a program 
product in a variety of forms, and that the present invention 
applies equally regardless of the particular type of signal 
bearing media used to actually carry out the distribution. 
Examples of signal bearing media include: recordable type 
media such as floppy disks and CD ROMs, and transmission 
type media such as digital and analog communication links. 

Referring now to FIG. 5, a specific configuration for 
config table 482 in accordance with the preferred embodi- 
ment provides a method for determining how transaction 
time agent 460 will collect transaction times. The first 
column is an identifier field that uniquely identifies an 
application. The specific format shown in FIG. 5 uses an 
application class identifier, followed by a period, then fol- 
lowed with the appropriate server identifier. The application 
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class identifier is a unique class identifier for a particular 
class of applications in network computing environment 
400. The server identifier identifies the server and applica- 
tion of interest. The combination of the two thus provide a 

5 unique identifier for each application that may run in net- 
work computing environment 400. 

The next six fields are threshold fields that contain six 
threshold values tl— 16. For the discussion herein, we assume 
the numbers in FIG. 5 are in milliseconds (ms). Each 

10 threshold value must be equal to or larger than the previous 
threshold value. For class 8.S-appl 1 (the first row in table 
482), threshold 1 is thus set to 1 ms; threshold 2 to 5 ms; 
threshold 3 to 10 ms; threshold 4 to 20 ms; and thresholds 
5 and 6 to 0 ms. For the threshold values in config table 482, 

15 a zero represents infinity. Thus, setting thresholds 5 and 6 to 
zero results in threshold 4 being the last defined threshold. 
The next field is a Time Out field that defines a maximum 
value that a transaction should never exceed. For the first 
row of config table 482, this value is set to 60 ms. The next 

20 column is for an elapsed notification threshold, which deter- 
mines a time value that, when exceeded, will cause a system 
to be notified. For the first row of config table 482, this value 
is set to 20 ms, which means that if the transaction time 
exceeds 20 ms, a system specified in the notification address 

25 list (in the last column of table 482) will be notified. For the 
first row of table 482, this is set to 20 ms, and the notification 
address list specifies server system 3, so server system 3 will 
be notified if the transaction time ever exceeds 20 ms for the 
application identified in the first column. The next field is for 

30 a minimum notification threshold value. This value is set to 
assure that a timeout is not repeatedly reported to the system 
in the notification address list. For the first row of config 
table 482, this value is set to 120 ms, meaning that if a 
notification. has occurred within the last 120 ms, we won't 

35 notify again. This inhibits needlessly repetitive notification 
of which the system in the notification address list is already 
aware. Note that the second row of config table 482 of FIG. 
5 has different thresholds set for tl-t6, has a different time 
out value (30 ms), and has zeroes for the elapsed notification 

40 threshold, the minimum notification threshold, the maxi- 
mum number of transactions, and has a null in the notifi- 
cation address list. This means that no system will be 
notified in the event of any abnormal occurrence, but the 
transaction time data will be available in the stats table 484 

45 if and when a transaction time manager (such as 414, 422, 
or 434) desire to access this data. 

With the config table 482 of FIG. 5 properly configured, 
transaction time agent 460 is now ready to collect transac- 
tion times for the listed applications. Referring to the first 

50 column of stats table 484 in FIG. 6, each entry in stats table 
484 is identified by an index that includes the server 
identifier, application class identifier, and instance identifier. 
The server identifier is an identifier that corresponds to a 
unique server process in the network, such as a uniform 

55 resource locator (URL) or an IP address and socket number. 
The application class identifier is one of a discrete list of 
values associated with the client application and maintained 
in a globally accessible registry in the network or configured 
manually for each application by the administrator. The 

60 application instance identifier uniquely identifies one of the 
application instances (i.e., client applications) in the net- 
work. A wildcard value (meaning "any") may be used in 
the index for the server identifier or the application class 
identifier or both. An index value of thus designates 

65 the global threshold configuration, defining thresholds 
which apply to all application class and server tuples, unless 
overridden by a more specific threshold configuration table 
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entry. The index allows efficient retrieval of only requested stats table 484 have seven counters. If only four thresholds 

data from stats table 484. The next column stores a total time were configured in config table 482, only five counters 

for all transactions stored in stats table 484 for the applica- would be required in stats table 484. Thus, after the agent is 

tion instance specified in the first column. The next seven initialized in step 720, the agent initializes the database to 

columns contain count values that correspond to the six 5 correspond to the configuration and status (step 722). 

thresholds set in config table 482. Count 1 (CI) is incre- The next step is that a client application instance 710 must 

me nted if the transaction time is below threshold tl in config register with the transaction time agent 460 (step 724). 

table 482. C2 is incremented if the transaction time is Monitoring all client instances is unnecessary and would 

between tl and t2. C3 is incremented if the transaction time result in excessive overhead. By requiring a client applica- 

is between t2 and l3. C4 is incremented if the transaction 10 tion instance 710 to register with the transaction time agent 

time is between t3 and t4. C5 is incremented if the trans- 460, only those client instances that request transaction time 

action time is between t4 and t5. C6 is incremented if the monitoring will be monitored. Steps 720-724 are performed 

transaction time is between 15 and t6. And C7 is incremented during the startup phase of the transaction monitoring, 

if the transaction time is over t6. The next field is a counter which may be suitably performed when network computing 

that keeps track of the number of time outs that occur. Thus, 15 environment 400 is powered-up and/or initialized, 

for the first row of stats table 484 (which corresponds to the The actual measurement and recording of transaction 

first row of config table 482 of FIG. 5), each time the times occurs in steps 726-734. When a transaction is started, 

transaction time exceeds 60 ms the time outs counter of stats the client application instance 710 notifies the transaction 

table 484 is incremented. The last column in stats table 484 time agent 460 in step 726 of the beginning of a transaction, 

is an elapsed time value list that provides that actual elapsed 20 The notification in step 726 for network computing envi- 

times for each transaction in a list. The counters provide data ronment 400 of FIG. 4 is performed by a client application 

that has a level of granularity defined by the thresholds set (such as 414 or 434) calling ARM API 470. Client applica- 

in config table 482. In many cases, the counters provide all tion instance 710 then performs the required interactions 

the data that is needed in monitoring transaction times. with the corresponding server application 712 in step 728. 

However, in some circumstances, more detailed information 25 When the transaction is complete, server application 712 

may be needed than is available from the counters. For notifies the client application instance 710 in step 730, and 

example, if the counters reveal certain information, the exact client instance 710 then notifies transaction time agent 460 

transaction times may be determined from the elapsed time of the end of the transaction in step 732. Again, for network 

value list. The transaction times are in a simple list format, computing environment 400, step 732 is performed by 

so determining the data of interest would generally require 30 calling ARM API 470. The transaction time agent then 

some post-processing, but these times are made available in updates the stats table in transaction time database 480 (step 

the case they are needed. 734) to reflect the newly-acquired transaction time. This 

The pro gramm ability of the transaction time agent 460 process repeats for each transaction that occurs for each 

through the structure and content of the config file 482 client application that has registered with the transaction 

allows great flexibility in reporting measured response 35 time agent 460. 

times. TheJcansacii fln time agent 460 may be con figured by Once the transaction time measuring infrastructure is in 

a transa ction time manag er-SQJheJia nsaction time manag er, place in a network computing environment as described 

- must collect data peri odically, or it may^e^configure.d^to herein, other functions may also be performed. For example, 

sen d noti fications to a transaction time managerial a speci- with a transaction time measurement mechanism 490 con- 

fiedTriteTvlll^ly^ifx^ exceeded. The 40 figured according to the first row in table 482 of FIG. 5, 

thresholds are suitably selected so^thartransacnon-rimTciata server system 3 will be notified if the elapsed notification 

is only transmitted on an exception basis, thereby minimiz- threshold is exceeded. This notification is represented as step 

ing network overhead. 740 of FIG. 7. In addition, at any time a transaction time 

The method of monitoring transaction times using the manager 714 may request to query a transaction time agent 

computer system of FIGS. 4-6 is represented in a flow 45 460 for the statistics regarding transaction times (step 750). 

diagram of FIG. 7. The various components are shown along In response to this query, transaction time agent 460 may 

the top of the diagram, with the arrows below indicating respond by sending the requested data from stats table 484 

which components perform the listed function on another to the requesting transaction time manager 714 (step 760). 

component. The client application instance 710 corresponds The present invention thus succeeds at providing a trans- 

to one of the client applications, such as client application 1 50 action time measurement mechanism that has one or more 

(414) or 3 (434) of FIG. 4. Transaction time agent 460 and transaction time managers running on server computer 

transaction lime database 480 are the same as shown in FIG. systems, a transaction time agent running on a client com- 

4. Server application 712 corresponds to a server application puter system that is coupled to the server computer system 

running on a server computer system, such as server appli- via a network, and a simple protocol for allowing them to 

cation 1 (412) or 3 (432). Transaction time manager 714 55 directly and efficiently communicate. The simple comrnu- 

corresponds to a transaction time manager, such as transac- nication protocol supports multiple transaction time manag- 

tion time managers 414, 422, or 434. ers in a network computing environment that may all 

The first step is fo r the transaction time manager 714 to communicate with a single client. Using a system in accor- 

initi alize the transaction time a gent 460 (step 720). This dance with the present invention, transaction times may be 
iniEalizati on includes writin g^gQnfi.guratioD-dAta-to.a.co.n^_60 accurately monitored without the network overhead associ- 

fig uration table, such as config table 482 _pj j 7 IG. 5 ,.Once the ated with prior art solutions. 

transaction time agent 460 is initialized, the transaction time While the invention has been particularly shown and 

agelfi~4ffljnin alizes the transaction time databa se 480 (step described with reference to preferred embodiments thereof, 

722) This initialization involves defining the appropriate it will be understood by those skilled in the art that various 

fields and counters to correspond to the configuration of the 65 changes in form and details may be made therein without 

transaction time agent 460. For example, the configuration departing from the spirit and scope of the invention. For 

table 482 of FIG. 5 has six thresholds. This mandates that example, it will be understood that, while various of the 
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conductors (connections) are shown in the drawing as single 
lines, they are not so shown in a limiting sense, and may 
comprise plural conductor (connections), as is understood in 
the art. 

What is claimed is: 5 

1. An apparatus comprising: 

(A) at least one server computer system running at least 
one server application; 

(B) at least one client computer system running at least 
one client application that corresponds to the at least 10 
one server application, the at least one client computer 
system being coupled to the at least one server com- 
puter system via a networking mechanism; and 

(C) a transaction time measurement mechanism compris- 
es 1 . 15 
(CI) at least one transaction time manager residing on 

and executed by the at least one server computer 
system; 

(C2) at least one transaction time agent residing on and 
executed by the at least one client computer system, 2Q 
the transaction time agent receiving notification of 
the beginning of a transaction from the at least one 
client application and receiving notification of the 
end of a transaction from the at least one client 
application; 25 

(D) an interface coupling the at least one transaction time 
manager to the at least one transaction time agent that 
supports a simple protocol that allows the transaction 
time manager to directly communicate with the trans- 
action time agent; and 3Q 

(E) a transaction time database coupled to the at least one 
transaction time agent, the transaction time database 
comprising: 

(El) at least one configuration table for storing at least 
one transaction time configuration, the configuration 35 
table defining a plurality of time thresholds; and 

(E2) at least one statistics table for storing transaction 
times according to the at least one transaction time 
configuration stored in the at least one configuration 
table, wherein the at least one statistics table defines 40 
at least one counter, each counter corresponding to a 
time interval defined by two of the plurality of time 
thresholds. 

2. The apparatus of claim 1 wherein the protocol com- 
prises a simple network management protocol (SNMP). 45 

3. The apparatus of claim 1 further comprising an appli- 
cation response monitoring (ARM) application program- 
ming interface (API) that is called by the at least one client 
application to indicate to the at least one transaction time 
agent the start and the end of a transaction. 50 

4. The apparatus of claim 1 wherein the at least one 
transaction time manager comprises a plurality of transac- 
tion time managers running on different server computer 
systems, 

5. An apparatus comprising: 55 

(A) a plurality of server computer systems running at least 
one server application; 

(B) a client computer system running at least one client 
application that corresponds to the at least one server 
application, the client computer system being coupled 60 
to the at least one server computer system via a 
networking mechanism; 

(C) a transaction time measurement mechanism compris- 
ing: 

(1) a plurality of transaction time managers residing on 65 
and executed by the plurality of server computer 
systems; 



(2) a transaction time agent residing on and executed by 
the client computer system, the transaction time 
agent receiving notification of the beginning of a 
transaction from the at least one client application 
and receiving notification of the end of a transaction 
from the at least one client application; and 

(3) an interface coupling the plurality of transaction 
time managers to the transaction time agent, the 
interface supporting a simple network management 
protocol (SNMP); 

(D) an application response monitoring (ARM) applica- 
tion programming interface (API) that is called by the 
at least one client application to indicate to the trans- 
action time agent the start and the end of a transaction; 
and 

(E) a transaction time database comprising: 

(1) a configuration table defining a plurality of time 
thresholds; and 

(2) a statistics table for storing transaction times 
according to the configuration stored in the configu- 
ration table, the statistics table defining at least one 
counter, each counter corresponding to a time inter- 
val defined by two of the plurality of time thresholds, 

6. A method for measuring transaction times in a net- 
worked computer system including at least one client com- 
puter system coupled via a network to at least one server 
computer system, the method comprising the steps of: 

(A) executing a transaction time manager on the at least 
one server computer system; 

(B) executing a transaction time agent on the at least one 
client computer system; 

(C) the transaction time manager initializing the transac- 
tion time agent; 

(D) the transaction time agent initializing a transaction 
time database according to the initialization of the 
transaction time agent, the initialization of the transac- 
tion time database comprising the steps of: 

(Dl) defining a plurality of time thresholds; and 
(D2) defining at least one counter, each counter corre- 
sponding to a time interval defined by two of the 
plurality of time thresholds; 

(E) at least one client application registering with the 
transaction time agent; 

(F) a registered client application notifying the transaction 
time agent of the beginning of a transaction; 

(G) incrementing each counter when a time period in the 
transaction lies between the two threshold values that 
correspond to the counter; 

(H) a server application corresponding to the registered 
client application notifying the registered client appli- 
cation of the end of the transaction; 

(I) the registered client application notifying the transac- 
tion time agent of the end of the transaction; and 

(J) the transaction time agent measuring the time from the 
beginning of the transaction to the end of the 
transaction, and updating the transaction time database 
with the time measurement. 

7. The method of claim 6 wherein steps (F) and (H) are 
performed by the registered client application calling an 
application response monitoring (ARM) application pro- 
gramming interface (API). 

8. The method of claim 6 further comprising the step of 
the transaction time agent notifying the transaction time 
manager when the time measurement exceeds a predeter- 
mined threshold. 
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9. The method of claim 6 further comprising the step of 
the transaction time manager requesting statistics stored in 
the transaction time database from the transaction time 
agent. 

10. The method of claim 9 further comprising the step of 
the transaction time agent retrieving the requested statistics 
from the transaction time database and returning the 
requested statistics to the transaction time manager. 

11. A program product comprising: 

(A) a transaction time measurement mechanism compris- 
ing: 

(1) at least one transaction time manager; 

(2) at least one transaction time agent that communi- 
cates with the transaction time manager via a simple 
protocol that allows the transaction time manager to 
directly communicate with the transaction time 
agent, the transaction time agent receiving notifica- 
tion of the beginning of a transaction from a client 
application and receiving notification of the end of a 
transaction from the client application; 

(3) a transaction time database that communicates with 
the at least one transaction time agent, the transac- 
tion time database comprising: 

at least one configuration table for storing at least 
one transaction time configuration, the configura- 
tion table defining a plurality of time thresholds; 
and 

at least one statistics table for storing transaction 
times according to the at least one transaction time 
configuration stored in the at least one configura- 
tion table, wherein the at least one statistics table 
defines at least one counter, each counter corre- 
sponding to a time interval defined by two of the 
plurality of time thresholds; and 

(B) signal bearing media bearing the transaction time 
measurement mechanism. 

12. The program product of claim 11 wherein the signal 
bearing media comprises recordable media. 

13. The program product of claim 11 wherein the signal 
bearing media comprises transmission media. 

14. The program product of claim 11 wherein the protocol 
comprises a simple network management protocol (SNMP). 



15. The program product of claim 11 wherein the trans- 
action time measurement mechanism further comprises an 
application response monitoring (ARM) application pro- 
gramming interface (API)) that is called to indicate the start 

5 and the end of a transaction. 

16. The program product of claim 11 wherein the at least 
one transaction time manager comprises a plurality of trans- 
action time managers running on different server computer 
systems. 

17. A program product comprising: 

(A) a transaction time measurement mechanism compris- 
ing: 

(1) at least one transaction time manager; 
15 (2) a transaction time agent that communicates with the 
transaction time manager via a simple protocol that 
allows the transaction time manager to directly com- 
municate with the transaction time agent; 

(3) an application response monitoring (ARM) appli- 
20 cation programming interface (API) that is called by 

a client application to indicate to the transaction time 
agent the start and the end of a transaction; 

(4) at least one configuration table for storing a plural- 
ity of transaction measurement configurations, each 
transaction measurement configuration defining a 
plurality of time thresholds; 

(5) at least one statistics table for storing transaction 
times according to at least one of the plurality of 

30 transaction measurement configurations stored in the 

at least one configuration table, the at least one 
statistics table defining at least one counter, each 
counter corresponding to a time interval defined by 
two of the plurality of time thresholds; and 

35 (B) signal bearing media bearing the transaction time 
measurement mechanism. 

18. The program product of claim 17 wherein the signal 
bearing media comprises recordable media. 

19. The program product of claim 17 wherein the signal 
40 bearing media comprises transmission media. 
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